Internet Surfer 2.0

home *** CD-ROM | disk | FTP | other *** search

/ Internet Surfer 2.0 / Internet Surfer 2.0 (Wayzata Technology) (1996).iso / pc / text / mac / faqs.114 < prev next >

Wrap

Text File | 1996-02-12 | 28.6 KB | 625 lines

Frequently Asked Questions (FAQS);faqs.114 Cristoph reports that Dell V.4 can be object-patched successfully to fix this. I'm told that the offending 11c97 is at exactly the same address in the Consensys 1.3 kernel. I do not know the status of the other ports. Another poster (Marc Boucher <marc@cam.org>) adds: On ESIX SVR4.0.3 Rev. A, the instruction movsbl in question can be changed to movzbl (as described above) with a binary-editor on file /etc/conf/pack.d/kernel/vm.o. At offset 0x11eb0, change 0xbe to 0xb6. Before patching, verify that your /etc/conf/pack.d/kernel/vm.o is the same as mine! On my system, the /bin/sum generated checksum of vm.o was "4440 222". The problem results from a sign-extension bug. The function lfubyte(), which is called by fubyte(), is declared as int lfubyte(char *addr); /* actually caddr_t */ The byte is fetched with val = *addr; which triggers sign extension. Casting addr to a unsigned char * or declaring it as such solves the problem. This bug is still present in stock USL 4.0.4. However, it has been fixed in Dell 2.2. VI. Destiny and Dell A source at at UNIX System Labs Europe claims that `Destiny' (the new Release 4.2) incorporates all of Dell UNIX's fixes to 4.0.3; thus, any bug for which a Dell fix is indicated above should be gone in Destiny. -- Send your feedback to: Eric Raymond = esr@snark.thyrsus.com Xref: bloom-picayune.mit.edu comp.mail.uucp:9809 news.answers:3989 Path: bloom-picayune.mit.edu!snorkelwacker.mit.edu!news.media.mit.edu!micro-heart-of-gold.mit.edu!news.bbn.com!usc!zaphod.mps.ohio-state.edu!cs.utexas.edu!uunet!airs!ian From: ian@airs.com (Ian Lance Taylor) Newsgroups: comp.mail.uucp,news.answers Subject: UUCP Internals Frequently Asked Questions Keywords: UUCP, protocol, FAQ Message-ID: <uucp-internals_721560602@airs.com> Date: 12 Nov 92 09:30:11 GMT Expires: 24 Dec 92 09:30:02 GMT Sender: news@airs.com Reply-To: ian@airs.com (Ian Lance Taylor) Followup-To: comp.mail.uucp Lines: 1187 Approved: news-answers-request@MIT.Edu Supersedes: <uucp-internals_719137803@airs.com> Archive-name: uucp-internals Version: $Revision: 1.10 $ Last-modified: $Date: 1992/10/22 03:55:21 $ This article was written by Ian Lance Taylor <ian@airs.com> and I may even update it periodically. Please send me mail about suggestions or inaccuracies. This article describes how the various UUCP protocols work, and discusses some other internal UUCP issues. It does not describe how to configure UUCP, nor how to solve UUCP connection problems, nor how to deal with UUCP mail. There are currently no FAQ postings on any of these topics, and I do not plan to write any. If you haven't read the news.announce.newusers articles, read them. This article is in digest format. Some newsreaders will be able to break it apart into separate articles. Please don't ask me how to do this, though. This article answers the following questions. If one of these questions is posted to comp.mail.uucp, please send mail to the poster referring her or him to this FAQ. There is no reason to post a followup, as most of us know the answer already. Sources What does "alarm" mean in debugging output? What are UUCP grades? What is the format of a UUCP lock file? What is the format of a UUCP X.* files? What is the UUCP protocol? What is the 'g' protocol? What is the 'f' protocol? What is the 't' protocol? What is the 'e' protocol? What is the 'G' protocol? What is the 'x' protocol? What is the 'd' protocol? What is the 'h' protocol? Thanks ---------------------------------------------------------------------- From: Sources Subject: Sources I took a lot of the information from Jamie E. Hanrahan's paper in the Fall 1990 DECUS Symposium, and from Managing UUCP and Usenet by Tim O'Reilly and Grace Todino (with contributions by several other people). The latter includes most of the former, and is published by O'Reilly & Associates, Inc. 103 Morris Street, Suite A Sebastopol, CA 95472 It is currently in its tenth edition. The ISBN number is 0-937175-93-5. Some information is originally due to a Usenet article by Chuck Wegrzyn. The information on execution files comes partially from Peter Honeyman. The information on the 'g' protocol comes partially from a paper by G.L. Chesson of Bell Laboratories, partially from Jamie E. Hanrahan's paper, and partially from source code by John Gilmore. The information on the 'f' protocol comes from the source code by Piet Berteema. The information on the 't' protocol comes from the source code by Rick Adams. The information on the 'e' protocol comes from a Usenet article by Matthias Urlichs. The information on the 'd' protocol comes from Jonathan Clark, who also supplied information about QFT. The FSUUCP information comes straight from Christopher J. Ambler. Although there are few books about UUCP, there are many about networks and protocols in general. I recommend two non-technical books which describe the sorts of things that are available on the network: ``The Whole Internet,'' by Ed Krol, and ``Zen and the Art of the Internet,'' by Brendan P. Kehoe. Good technical discussions of networking issues can be found in ``Internetworking with TCP/IP,'' by Douglas E. Comer and David L. Stevens and in ``Design and Validation of Computer Protocols'' by Gerard J. Holzmann. ------------------------------ From: alarm Subject: What does "alarm" mean in debugging output? The debugging output of many versions of UUCP (but not Taylor UUCP) will include messages like alarm 1 or pkcget: alarm 1 This message means that the UUCP package has timed out while waiting for some sort of response from the remote system. This normally indicates some sort of connection problem. For example, the modems might have lost their connection, or perhaps one of the modems will not transmit the XON and XOFF characters, or perhaps one side or the other is dropping characters. It can also mean that the packages disagree about some aspect of the UUCP protocol, although this is less common. Using the information in the rest of this posting, you should be able to figure out what type of data your UUCP was expecting to receive. This may give some indication as to exactly what the problem is. It is difficult to be more specific, since there are many possiblities. ------------------------------ From: UUCP-grades Subject: What are UUCP grades? Modern UUCP packages support grades for each command. The grades generally range from 'A' (the highest) to 'Z' followed by 'a' to 'z'. Some UUCP packages also support '0' to '9' before 'A'. Some UUCP packages may permit any ASCII character as a grade. On Unix, these grades are encoded in the name of the command file. A command file name generally has the form C.nnnngssss where nnnn is the remote system name for which the command is queued, g is a single character grade, and ssss is a four character sequence number. For example, a command file created for the system ``airs'' at grade 'Z' might be named C.airsZ2551 The remote system name will be truncated to seven characters, to ensure that the command file name will fit in the 14 character file name limit of the traditional Unix file system. UUCP packages which have no other means of distinguishing which command files are intended for which systems thus require all systems they connect to to have names that are unique in the first seven characters. Some UUCP packages use a variant of this format which truncates the system name to six characters. HDB and Taylor UUCP use a different spool directory format, which allows up to fourteen characters to be used for each system name. The sequence number in the command file name may be a decimal integer, or it may be a hexadecimal integer, or it may contain any alphanumeric character. Different UUCP packages are different. FSUUCP (a DOS based UUCP and news package) uses up to 8 characters for file names in the spool (this is a DOS file name limitation; actually, with the extension, 11 characters are available, but FSUUCP reserves that for future use). FSUUCP defaults mail to grade D, and news to grade N, except that when the grade of incoming mail can be determined, that grade is preserved if the mail is forwarded to another system. Mail and news are currently the only 2 types of transfers supported. The default grades may be changed by editing the MAIL.RC file for mail, or the FSUUCP.CFG file for news. I do not know how command grades are handled in other non-Unix UUCP packages. Modern UUCP packages allow you to restrict file transfer by grade depending on the time of day. Typically this is done with a line in the Systems (or L.sys) file like this: airs Any/Z,Any2305-0855 ... This allows grades 'Z' and above to be transferred at any time. Lower grades may only be transferred at night. I believe that this grade restriction applies to local commands as well as to remote commands, but I am not sure. It may only apply if the UUCP package places the call, not if it is called by the remote system. Taylor UUCP can use the ``timegrade'' and ``call-timegrade'' commands to achieve the same effect (and supports the above format when reading Systems or L.sys). This sort of grade restriction is most useful if you know what grades are being used at the remote site. The default grades used depend on the UUCP package. Generally uucp and uux have different defaults. A particular grade can be specified with the -g option to uucp or uux. For example, to request execution of rnews on airs with grade 'd', you might use something like uux -gd - airs!rnews <article Uunet queues up mail at grade 'C', but increases the grade based on the size. News is queued at grade 'd', and file transfers at grade 'n'. The example above would allow mail (below some large size) to be received at any time, but would only permit news to be transferred at night. ------------------------------ From: UUCP-lock-file Subject: What is the format of a UUCP lock file? This discussion applies only to Unix. I have no idea how UUCP locks ports on other systems. UUCP creates files to lock serial ports and systems. On most if not all systems these same lock files are also used by cu to coordinate access to serial ports. On some systems getty also uses these lock files, often under the name uugetty. The lock file normally contains the process ID of the locking process. This makes it easy to determine whether a lock is still valid. The algorithm is to create a temporary file and then link it to the name that must be locked. If the link fails because a file with that name already exists, the existing file is read to get the process ID. If the process still exists, the lock attempt fails. Otherwise the lock file is deleted and the locking algorithm is retried. Older UUCP packages put the lock files in the main UUCP spool directory, /usr/spool/uucp. HDB UUCP generally puts the lock files in a directory of their own, usually /usr/spool/locks or /etc/locks. The original UUCP lock file format encodes the process ID as a four byte binary number. The order of the bytes is host-dependent. HDB UUCP stores the process ID as a ten byte ASCII decimal number, with a trailing newline. For example, if process 1570 holds a lock file, it would contain the eleven characters space, space, space, space, space, space, one, five, seven, zero, newline. Some versions of UUCP add a second line indicating which program created the lock (uucp, cu, or getty/uugetty). I have also seen a third type of UUCP lock file which does not contain the process ID at all. The name of the lock file is traditionally "LCK.." followed by the base name of the device. For example, to lock /dev/ttyd0 the file LCK..ttyd0 would be created. On SCO Unix, the lock file name is always forced to lower case even if the device name has upper case letters. System V Release 4 UUCP names the lock file using the major and minor device numbers rather than the device name. The file is named LK.XXX.YYY.ZZZ, where XXX, YYY and ZZZ are all three digit decimal numbers. XXX is the major device number of the device holding the directory holding the device file (e.g., /dev). YYY is the major device number of the device file itself. ZZZ is the minor device number of the device file itself. If s holds the result of passing the device to the stat system call (e.g., stat ("/dev/ttyd0", &s)), the following line of C code will print out the corresponding lock file name: printf ("LK.%03d.%03d.%03d", major (s.st_dev), major (s.st_rdev), minor (s.st_rdev)); The advantage of this system is that even if there are several links to the same device, they will all use the same lock file name. ------------------------------ From: X-file Subject: What is the format of a UUCP X.* files? UUCP X.* files control program execution. They are created by uux. They are transferred between computers just like any other file. The uuxqt daemon reads them to figure out how to execute the job requested by uux. An X.* file is simply a text file. The first character of each line is a command, and the remainder of the line supplies arguments. The following commands are defined: C command This gives the command to execute, including the program and all arguments. For example, C rmail ian@airs.com U user system This names the user who requested the command, and the system from which the request came. I standard-input This names the file from which standard input is taken. If no standard input file is given, the standard input will probably be attached to /dev/null. If the standard input file is not from the system on which the execution is to occur, it will also appear in an F command. O standard-output [ system ] This names the standard output file. The optional second argument names the system to which the file should be sent. If there is no second argument, the file should be created on the executing system. F required-file [ filename-to-use ] The F command can appear multiple times. Each F command names a file which must exist before the execution can proceed. This will usually be a file which is transferred from the system on which uux was executed, but it can also be a file from the local system or some other system. If the file is not from the local system, then the command will usually name a file in the spool directory. If the optional second argument appears, then the file should be copied to the execution directory under that name. This is necessary for any file other than the standard input file. If the standard input file is not from the local system, it will appear in both an F command and an I command. R requestor-address This is the address to which mail about the job should be sent. It is relative to the system named in the U command. If the R command does not appear, then mail is sent to the user named in the U command. Z This command takes no arguments. It means that a mail message should be sent if the command failed. This is the default behaviour for most modern UUCP packages, and for them the Z command does not actually do anything. N This command takes no arguments. It means that no mail message should be sent, even if the command failed. n This command takes no arguments. It means that a mail message should be sent if the command succeeded. Normally a message is sent only if the command failed. B This command takes no arguments. It means that the standard input should be returned with any error message. This can be useful in cases where the input would otherwise be lost. e This command takes no arguments. It means that the command should be processed with /bin/sh. For some packages this is the default anyhow. Most packages will refuse to execute complex commands or commands containing wildcards, because of the security holes this opens. E This command takes no arguments. It means that the command should be processed with the execve system call. For some packages this is the default anyhow. M status-file This command means that instead of mailing a message, the message should be copied to the named file on the system named by the U command. # comment This command is ignored, as is any other unrecognized command. Here is an example. Given the following command executed on system test1 uux - test2!cat - test2!~ian/bar !qux '>~/gorp' (this is only an example, as most UUCP systems will not permit the cat command to be executed) Taylor UUCP will produce the following X. file: U ian test1 F D.test1N003r qux O /usr/spool/uucppublic test1 F D.test1N003s I D.test1N003s C cat - ~ian/bar qux The standard input will be read into a file and then transferred to the file D.test1N003s on system test2, and the file qux will be transferred to D.test1N003r on system test2. When the command is executed, the latter file will be copied to the execution directory under the name qux. Note that since the file ~ian/bar is already on the execution system, no action need be taken for it. The standard output will be collected in a file, then copied to the directory /usr/spool/uucppublic on the system test1. ------------------------------ From: UUCP-protocol Subject: What is the UUCP protocol? The UUCP protocol is a conversation between two UUCP packages. A UUCP conversation consists of three parts: an initial handshake, a series of file transfer requests, and a final handshake. Before the initial handshake, the caller will usually have logged in the called machine and somehow started the UUCP package there. On Unix this is normally done by setting the shell of the login name used to /usr/lib/uucp/uucico. All messages in the initial handshake begin with a ^P (a byte with the octal value \020) and end with a null byte (\000). A few systems end these messages with a line feed character (\012) instead of a null byte; the examples below assume a null byte is being used. Some options below are supported by QFT, which stands for Queued File Transfer, and is (or was) an internal Bell Labs version of UUCP. Some are supported by FSUUCP, which is a DOS based UUCP and news package. The initial handshake goes as follows. It is begun by the called machine. called: \020Shere=hostname\000 The hostname is the UUCP name of the called machine. Older UUCP packages do not output it, and simply send \020Shere\000. caller: \020Shostname options\000 The hostname is the UUCP name of the calling machine. The following options may appear (or there may be none): -QSEQ Report sequence number for this conversation. The sequence number is stored at both sites, and incremented after each call. If there is a sequence number mismatch, something has gone wrong (somebody may have broken security by pretending to be one of the machines) and the call is denied. If the sequence number changes on one of the machines, perhaps because of an attempted breakin or because a disk backup was restored, the sequence numbers on the two machines must be reconciled manually. This is not supported by FSUUCP. -xLEVEL Requests the called system to set its debugging level to the specified value. This is not supported by all systems. -pGRADE -vgrade=GRADE Requests the called system to only transfer files of the specified grade or higher. This is not supported by all systems. Some systems support -p, some support -vgrade=. -R Indicates that the calling UUCP understands how to restart failed file transmissions. Supported only by System V Release 4 UUCP and QFT. -ULIMIT Reports the ulimit value of the calling UUCP. The limit is specified as a base 16 number in C notation (e.g., -U0x1000000). This number is the number of 512 byte blocks in the largest file which the calling UUCP can create. The called UUCP may not transfer a file larger than this. Supported only by System V Release 4 UUCP, QFT and FSUUCP. FSUUCP reports the lesser of the available disk space on the spool directory drive and the ulimit variable in FSUUCP.CFG. -N Indicates that the calling UUCP understands the Taylor UUCP size limiting extensions. Supported only by Taylor UUCP and FSUUCP. called: \020ROK\000 There are actually several possible responses. ROK The calling UUCP is acceptable, and the handshake proceeds to the protocol negotiation. Some options may also appear; see below. ROKN The calling UUCP is acceptable, it specified -N, and the called UUCP also understands the Taylor UUCP size limiting extensions. Supported only by Taylor UUCP and FSUUCP. RLCK The called UUCP already has a lock for the calling UUCP, which normally indicates the two machines are already communicating. RCB The called UUCP will call back. This may be used to avoid impostors (but only one machine out of each pair should call back, or no conversation will ever begin). RBADSEQ The call sequence number is wrong (see the -Q discussion above). RLOGIN The calling UUCP is using the wrong login name. RYou are unknown to me The calling UUCP is not known to the called UUCP, and the called UUCP does not permit connections from unknown systems. Some versions of UUCP just drop the line rather than sending this message. If the response is ROK, the following options are supported by System V Release 4 UUCP and QFT. -R The called UUCP knows how to restart failed file transmissions. -ULIMIT Reports the ulimit value of the called UUCP. The limit is specified as a base 16 number in C notation. This number is the number of 512 byte blocks in the largest file which the called UUCP can create. The calling UUCP may not send a file larger than this. Also supported by FSUUCP. -xLEVEL I'm not sure just what this means. It may request the calling UUCP to set its debugging level to the specified value. If the response is not ROK (or ROKN) both sides hang up the phone, abandoning the call. called: \020Pprotocols\000 Note that the called UUCP outputs two strings in a row. The protocols string is a list of UUCP protocols supported by the caller. Each UUCP protocol has a single character name. These protocols are discussed in more detail later in this document. For example, the called UUCP might send \020Pgf\000. caller: \020Uprotocol\000 The calling UUCP selects which protocol to use out of the protocols offered by the called UUCP. If there are no mutually supported protocols, the calling UUCP sends \020UN\000 and both sides hang up the phone. Otherwise the calling UUCP sends something like \020Ug\000. Most UUCP packages will consider each locally supported protocol in turn and select the first one supported by the called UUCP. With some versions of HDB UUCP, this can be modified by giving a list of protocols after the device name in the Devices file or the Systems file. For example, to select the 'e' protocol in Systems, airs Any ACU,e ... or in Devices, ACU,e ttyXX ... Taylor UUCP provides the ``protocol'' command which may be used either for a system or a port. After the protocol has been selected and the initial handshake has been completed, both sides turn on the selected protocol. For some protocols (notably 'g') a further handshake is done at this point. Each protocol supports a method for sending a command to the remote system. This method is used to transmit a series of commands between the two UUCP packages. At all times, one package is the master and the other is the slave. Initially, the calling UUCP is the master. If a protocol error occurs during the exchange of commands, both sides move immediately to the final handshake. The master will send one of four commands: S, R, X or H. Any file name referred to below is either an absolute pathname beginning with "/", a public directory pathname beginning with "~/", a pathname relative to a user's home directory beginning with "~USER/", or a spool directory file name. File names in the spool directory are not pathnames, but instead are converted to pathnames within the spool directory by UUCP. They always begin with "C." (for a command file created by uucp or uux), "D." (for a data file created by uucp, uux or by an execution, or received from another system for an execution), or "X." (for an execution file created by uux or received from another system). master: S FROM TO USER -OPTIONS TEMP MODE NOTIFY SIZE The S and the - are literal characters. This is a request by the master to send a file to the slave. FROM The name of the file to send. If the C option does not appear in OPTIONS, the master will actually open and send this file. Otherwise the file has been copied to the spool directory, where it is named TEMP. The slave ignores this field unless TO is a directory, in which case the basename of FROM will be used as the file name. If FROM is a spool directory filename, it must be a data file created for or by an execution, and must begin with "D.". TO The name to give the file on the slave. If this field names a directory the file is placed within that directory with the basename of FROM. A name ending in `/' is taken to be a directory even if one does not already exist with that name. If TO begins with `X.', an execution file will be created on the slave. Otherwise, if TO begins with `D.' it names a data file to be used by some execution file. Otherwise, TO should not be in the spool directory. USER The name of the user who requested the transfer. OPTIONS A list of options to control the transfer. The following options are defined (all options are single characters): C The file has been copied to the spool directory (the master should use TEMP rather than FROM). c The file has not been copied to the spool directory (this is the default). d The slave should create directories as necessary (this is the default). f The slave should not create directories if necessary, but should fail the transfer instead. m The master should send mail to USER when the transfer is complete (not supported by FSUUCP). n The slave should send mail to NOTIFY when the transfer is complete (not supported by FSUUCP). TEMP If the C option appears in OPTIONS, this names the file to be sent. Otherwise if FROM is in the spool directory, TEMP is the same as FROM. Otherwise TEMP may be a dummy string, such as "D.0". After the transfer has been succesfully completed, the master will delete the file TEMP. MODE This is an octal number giving the mode of the file on MASTER. If the file is not in the spool directory, the slave will always create it with mode 0666, except that if (MODE & 0111) is not zero (the file is executable), the slave will create the file with mode 0777. If the file is in the spool directory, some UUCP packages will use the algorithm above and some will always create the file with mode 0600. This field is not used by FSUUCP, since it is meaningless on DOS. NOTIFY This field may not be present, and in any case is only meaningful if the n option appears in OPTIONS. If the n option appears, then when the transfer is successfully